Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000058_owner-urn-ietf _Wed Nov 6 09:31:43 1996.msg

Internet Message Format | 1997-02-19 | 10KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09129 for urn-ietf-out; Wed, 6 Nov 1996 09:31:43 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09124 for <[e-mail]>; Wed, 6 Nov 1996 09:31:40 -0500
Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA09823  (mail destined for [e-mail]); Wed, 6 Nov 96 09:31:29 -0500
Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:31:04 +0000
Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:30:46 +0000
Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Wed, 6 Nov 96 14:29:57 GMT
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 06 Nov 1996 14:32:07 +0000
To: Terry Allen <[e-mail]>
From: Bob Briscoe <[e-mail]>
Subject: RE: [URN] Persistence as part of URN framework
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Bob Briscoe <[e-mail]>
Errors-To: [e-mail]

Apologies. I had better explain myself better - I've used terminology from a
different planet (ISO Open Distributed Processing Reference Model) and been
sloppy with it. I'll stick to URN terminology, and be more strict...

I'll answer the general point at the end first.

>I don't see where you get the idea that a URN has a TTL at all.  Where
>does the NAPTR proposal say it does?  (maybe I missed something)

NAPTR doesn't. I said I was criticising the URN framework, not NAPTR, which
I just mentioned as an example of what you get if you follow the framework.

I'm saying the framework should require that any solution (like NAPTR)
should allow the option of specifying the longevity of the ability to
resolve the name.

If you don't allow this, the only people who will ever use this will be
non-commercial organisations who think they are free to say "for ever"
without regard to the consequences. No commercial organisation would enter
into anything which included any commitment "for ever".

At 11:40 05/11/96 -0800, Terry Allen wrote:
>Bob Briscoe writes:
>
>| The point I'm making is that if we (BT) sell or give away a URN (in our role
>| as an Internet Service Provider), to give our customers the ability to
>
>Your role as ISP does not mean that you have to take on the role of
>name space owner.

I meant that as an ISP we might want to also operate a name space resolver
service for a delegated portion of a scheme name space (without necessarily
owning the name space itself).

As this dual role is obviously causing confusion, lets say BT NSR are the
name space resolver and BT ISP wants to be a customer of the resolver
service because they consider it commercially advantageous to attract
customers in by proving they have a route out if they want.

>
>| switch suppliers but keep their resource names, we will contract with them
>| to do this for a certain time. The URN service should be able to reflect
>
>You will contract with them to do what for a certain time?  Resolve
>URNs from a name space you control?  I wouldn't want to contract with
>a name space owner that promised to resolve my URNs only so long as
>I used them as my ISP.  Am I missing something?

I meant exactly the opposite. That BT ISP would be "retailing" the URN from
BT NSR (the "URN wholesaler") to BT ISP's customer, Jo Blow, so she could
switch to a different ACME ISP but still keep her URNs. Then ACME ISP might
pay the annual URN maintenance fees to BT NSR, and pass the cost on to Jo Blow.

>
>| this contractual fact so that other independent systems can know how long
>| they can rely on that person's URN (e.g. so the third party's content
>| management system can re-check HREFs as they are about to become obsolete
>| rather than by polling).
>
>What would make them obsolete?  Or do you mean nonresolvable?

Sorry, I meant unresolvable. I accept that a URN would never be obsolete if
you disallow re-use (but see below as to why this distinction is irrelevant).

>
>| Once we have contracted to do this, we will *have to* ensure the URN is
>| still accessible in terms of network infrastructure and servers. If the user
>
>And in the same way as before; if your client moves a resource to
>another URL, he has to tell you so.  What changes about that when
>your client moves his resources to another system?

Nothing. I'm just saying we need to lay down how long our commitment is
before we start. If BT NSR commit to 50 years, while the International
Chamber of Commerce NSR commits to 200 years and Dodgy NSR commits to 5
years, Jo Blow, would have a market differentiator for her to decide which
ISP she wanted, by which NSR they backed if name longevity was important to her.

All I'm saying is that for a multi-collaborative project like the Web, this
meta-data (longevity) about a resolution service for a portion of a name
scheme is the most useful characteristic to tag URNs with, so that other
services that use URNs it resolves can know when to re-check their validity
(resolvability).

I should clarify that I'm talking about the longevity of the resolution
service for a portion of the name space, not of the whole naming scheme
itself. The eventuality I envisage is that if this whole idea gets
superceded, so we've got very few resolution requests coming in for our
portion, we want to be able to wind up without jarring everyone off by
surprising them with a notice to quit. Effectively it's putting the
principles of ISO9000 (Quality and all that) into even the very long term
committments we make. By saying in advance we're going to stop at a certain
time, we can always extend it if the thing is still useful, but we have the
option not to.

This scenario assumes it is unlikely that we will be able to find someone
else to take over resolving our bit of the name space - if we don't see a
benefit in doing it ourselves, it's unlikely someone else will.

>
>| has thrown away their Web browser and got SuperCrap5 instead, that's not our
>| concern. I'm not saying we are planning doing this, I'm just laying out the
>| processes a commercial company would go through before marketing URNs.
>
>I don't get the point about the user changing browsers.

My reply was to Mark Fisher's posting, in particular his phrase:
>>>Even then, the data would only
>>>persist as long as technical means remained to read the persistent data.

I was saying BT NSR can commit to providing service and comms infrastructure
for a set length of time, but if the user throws away the hardware or
software they used to access BT NSR's service, that's not BT NSR's problem.
The phrase "throws away" includes the them breaking it (e.g. by installing
an incompatible OS).

>
>| That's just PURLs - saying certain names are more persistent than others.
>| What I'm saying is that for URNs to mean anything, you need the *optional*
>| capability to say *how* persistent you mean when you say "pretty persistent"
>| because "for ever" is just meaningless. It must be optional because some
>
>Well, no it isn't.  URNs are not to be reassigned; is that more meaningful
>for you than "forever"?  There are no guarantees (nor can there be any)
>that a URN will be resolvable over the Internet forever.

Sorry, yes, URNs are superficially better than PURLs in this respect.
However, the "no reassignment" rule is unenforceable unless a resolver is
available to test whether the URN has already been assigned (this resolver
might be a wodge of print-out printed at the point that the on-line resolver
was shut down for ever, but this would only be useful in proving a URN had
been reassigned after the event). So pragmatically, the "no reassignment"
rule amounts to "no reassignment for the life of the resolver", which leads
back to my request for a TTL specified for the resolver.

>
>| people don't want to think about how long "persistent" means. Others might
>| not want anyone to infer how long they expect to be in business from the
>| length of their TTLs!
>|
>| A naming service should at minimum deal with the characteristics that you
>| can hang on a name
>| - persistence of the name
>
>The *name* is persistent, period.  Resolution is another matter.

Prove it (see previous comment)!

>I don't know what you mean to refer to when you write "naming service".

Sorry, I mean "name space resolver service".

Final comment:
If you accept that pragmatically, URNs don't exist for ever (because they
only exist as long as anyone can prove they exist), you can still have the
"no reassignment" rule for people to keep to on best effort. IOW, just
because urn:duns:001234567:Dunn&Bradstreet_Collapse.report stops being
resolvable, anyone who knew of broken references to it well into the future,
shouldn't deliberately re-use it for something else.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm